Security system for generating keys from access rules in a decentralized manner and methods therefor

ABSTRACT

Improved system and approaches for decentralized key generation are disclosed. The keys that can be generated include both public keys and private keys. The public keys are arbitrary strings that embed or encode access restrictions. The access restrictions are used to enforce access control policies. The public keys are used to encrypt some or all portions of files. The private keys can be generated to decrypt the portions of the files that have been encrypted with the public keys. By generating keys in a decentralized manner, not only are key distribution burdens substantially eliminated but also off-line access to encrypted files is facilitated.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation-In-Part (CIP) of U.S. patentapplication Ser. No. 10/075,194, filed Feb. 12, 2002, and entitled“SYSTEM AND METHOD FOR PROVIDING MULTI-LOCATION ACCESS MANAGEMENT TOSECURED ITEMS,” which is hereby incorporated by reference for allpurposes, and which claims priority of U.S. Provisional Application No.60/339,634, filed Dec. 12, 2001, and entitled “PERVASIVE SECURITYSYSTEMS,” which is hereby incorporated by reference for all purposes.

This application is also related to: (i) U.S. application Ser. No.10/186,203, filed Jun. 26, 2002, and entitled “METHOD AND SYSTEM FORIMPLEMENTING CHANGES TO SECURITY POLICIES IN A DISTRIBUTED SECURITYSYSTEM,” which is hereby incorporated by reference for all purposes;(ii) U.S. patent application Ser. No. 10/206,737, filed Jul. 26, 2002,and entitled “METHOD AND SYSTEM FOR UPDATING KEYS IN A DISTRIBUTEDSECURITY SYSTEM,” which is hereby incorporated by reference for allpurposes; (iii) U.S. patent application Ser. No. 10/159,537, filed May31, 2002, and entitled “METHOD AND APPARATUS FOR SECURING DIGITALASSETS,” which is hereby incorporated by reference for all purposes; and(iv) U.S. patent application Ser. No. 10/074,825, filed Feb. 12, 2002,and entitled “METHOD AND APPARATUS FOR ACCESSING SECURED ELECTRONIC DATAOFF-LINE,” which is hereby incorporated by reference for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to security systems for data and, moreparticularly, to security systems that protect data in an inter/intraenterprise environment.

2. Description of Related Art

The Internet is the fastest growing telecommunications medium inhistory. This growth and the easy access it affords have significantlyenhanced the opportunity to use advanced information technology for boththe public and private sectors. It provides unprecedented opportunitiesfor interaction and data sharing among businesses and individuals.However, the advantages provided by the Internet come with asignificantly greater element of risk to the confidentiality andintegrity of information. The Internet is an open, public andinternational network of interconnected computers and electronicdevices. Without proper security means, an unauthorized person ormachine may intercept any information traveling across the Internet andeven get access to proprietary information stored in computers thatinterconnect to the Internet, but are otherwise generally inaccessibleby the public.

There are many efforts in progress aimed at protecting proprietaryinformation traveling across the Internet and controlling access tocomputers carrying the proprietary information. Cryptography allowspeople to carry over the confidence found in the physical world to theelectronic world, thus allowing people to do business electronicallywithout worries of deceit and deception. Every day hundreds of thousandsof people interact electronically, whether it is through e-mail,e-commerce (business conducted over the Internet), ATM machines, orcellular phones. The perpetual increase of information transmittedelectronically has lead to an increased reliance on cryptography.

One of the ongoing efforts in protecting the proprietary informationtraveling across the Internet is to use one or more cryptographictechniques to secure a private communication session between twocommunicating computers on the Internet. The cryptographic techniquesprovide a way to transmit information across an unsecure communicationchannel without disclosing the contents of the information to anyoneeavesdropping on the communication channel. Using an encryption processis a cryptographic technique whereby one party can protect the contentsof the data in transit from access by an unauthorized third party, yetthe intended party can read the data using a corresponding decryptionprocess.

A firewall is another security measure that protects the resources of aprivate network from users of other networks. However, it has beenreported that many unauthorized accesses to proprietary informationoccur from the inside, as opposed to from the outside. An example ofsomeone gaining unauthorized access from the inside is when restrictedor proprietary information is accessed by someone within an organizationwho is not supposed to do so. Due to the open nature of the Internet,contractual information, customer data, executive communications,product specifications, and a host of other confidential and proprietaryintellectual property remain available and vulnerable to improper accessand usage by unauthorized users within or outside a supposedly protectedperimeter.

Many businesses and organizations have been looking for effective waysto protect their proprietary information. Typically, businesses andorganizations have deployed firewalls, Virtual Private Networks (VPNs),and Intrusion Detection Systems (IDS) to provide protection.Unfortunately, these various security means have been proveninsufficient to reliably protect proprietary information residing onprivate networks. For example, depending on passwords to accesssensitive documents from within often causes security breaches when thepassword of a few characters long is leaked or detected. Consequently,various cryptographic means are deployed to provide restricted access toelectronic data in security systems.

Various security criteria, such as encryption or decryption keys, areoften used to facilitate the restricted access in the security systems.However, prolonged use of the security criteria, if not updated, canimpose threats to the security of the protected data. While periodicupdates to keys can help preserve security, the generation anddistribution of key (such as in a network-based system) is a significantburden to system resources. When the system maintains a large number ofkeys for numerous file and users, the demand of system resources is evenmore taxing. Therefore, there is a need to provide more effective waysto utilize the security criteria (e.g. the keys) for security systems tosecure and protect resources.

SUMMARY OF THE INVENTION

The invention relates to improved approaches for decentralized keygeneration. The keys that can be generated include both public keys andprivate keys. The public keys are arbitrary strings that embed or encodeaccess restrictions. The access restrictions are used to enforce accesscontrol policies. The public keys are used to encrypt some or allportions of files. The private keys can be generated to decrypt theportions of the files that have been encrypted with the public keys. Bygenerating keys in a decentralized manner, not only are key distributionburdens substantially eliminated but also off-line access to encryptedfiles is facilitated.

The invention can be implemented in numerous ways, including as amethod, system, device, and computer readable medium. Severalembodiments of the invention are discussed below.

As a method for encrypting a file, one embodiment of the inventionincludes at least the acts of: obtaining access rules to be imposed;producing a rules string in accordance with the access rules; generatinga public key based on the rules string; and encrypting at least aportion of the file using the public key.

As another method for encrypting a file, one embodiment of the inventionincludes at least the acts of: identifying access rules to be imposed;producing a rules string in accordance with the access rules; obtaininga key block of the file to be encrypted, the file including at least thekey block and a data block; generating a public key for the key blockbased on the rules string; and encrypting the key block portion of thefile using the public key.

As a method for decrypting a secured file that has been previouslyencrypted, one embodiment of the invention includes at least the actsof: obtaining a key string associated with the secured file to bedecrypted; identifying access rules associated with the key string;evaluating the access rules to determine whether a user requestingaccess to the secured file is permitted access to the secured file;denying access to the secured file when said evaluating determines thatthe access rules do not permit the user to access the secured file;generating a private key based on the access rules and a master key whensaid evaluating determines that the access rules permit the user toaccess the secured file; and decrypting, following said generating, atleast a portion of the secured file for access thereto by the userthrough use of the private key.

As another method for decrypting a secured file that has been previouslyencrypted, one embodiment of the invention includes at least the actsof: obtaining a key string associated with the secured file to bedecrypted; identifying access rules associated with the key string;obtaining an encrypted key block of the secured file; evaluating theaccess rules to determine whether a user requesting access to thesecured file is permitted access to the secured file; denying access tothe secured file when said evaluating determines that the access rulesdo not permit the user to access the secured file; generating a privatekey based on the access rules and a master key when said evaluatingdetermines that the access rules permit the user to access the securedfile; decrypting, following said generating, the encrypted key block toobtain a file key; and thereafter decrypting at least a portion of thesecured file for access thereto by the user through use of the file key.

As a computer readable medium including at least computer program codefor encrypting a file, one embodiment of the invention includes atleast: computer program code for obtaining access rules to be imposed;computer program code for producing a rules string in accordance withthe access rules; computer program code for generating a public keybased on the rules string; and computer program code for encrypting atleast a portion of the file using the public key.

As a computer readable medium including at least computer program codefor decrypting a secured file that has been previously encrypted, oneembodiment of the invention includes at least: computer program code forobtaining a key string associated with the secured file to be decrypted;computer program code for identifying access rules associated with thekey string; computer program code for evaluating the access rules todetermine whether a user requesting access to the secured file ispermitted access to the secured file; computer program code for denyingaccess to the secured file when said evaluating determines that theaccess rules do not permit the user to access the secured file; computerprogram code for generating a private key based on the access rules anda master key when said evaluating determines that the access rulespermit the user to access the secured file; and computer program codefor decrypting at least a portion of the secured file for access theretoby the user through use of the private key.

Other objects, features, and advantages of the present invention willbecome apparent upon examining the following detailed description of anembodiment thereof, taken in conjunction with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the presentinvention will become better understood with regard to the followingdescription, appended claims, and accompanying drawings wherein:

FIG. 1A shows a basic system configuration in which the invention may bepracticed in accordance with an embodiment thereof.

FIG. 1B shows another system configuration in which the invention may bepracticed in accordance with an embodiment thereof.

FIG. 1C shows still another system configuration in which the inventionmay be practiced in accordance with an embodiment thereof.

FIG. 1D shows internal construction blocks of a computing device inwhich the invention may be implemented and executed.

FIG. 2A is a block diagram of securing a created document according toone embodiment of the invention.

FIG. 2B illustrates an exemplary structure of a secured documentincluding a header and an encrypted portion.

FIG. 3A illustrates a representative data structure of a secured fileincluding a header and an encrypted data portion according to oneembodiment of the invention.

FIG. 3B is a functional block diagram of a server device in accordancewith one embodiment of the invention.

FIG. 3C is a functional block diagram of a local server device accordingto one embodiment of the invention.

FIG. 3D is a functional block diagram of a client machine according toone embodiment of the invention.

FIG. 4 is a block diagram of a file security system according to oneembodiment of the invention.

FIG. 5 is a block diagram of a distributed file security systemaccording to one embodiment of the invention.

FIG. 6 is a flow diagram of access rules based encryption processingaccording to one embodiment of the invention.

FIG. 7 is a flow diagram of access rules based decryption processingaccording to one embodiment of the invention.

FIG. 8 is a flow diagram of access rules based encryption processingaccording to another embodiment of the invention.

FIG. 9 is a flow diagram of access rules based decryption according toanother embodiment of the invention.

FIG. 10 illustrates flow diagrams of an authorization process accordingto one embodiment of the invention.

FIG. 11 shows a flowchart of a user authentication process that may beimplemented in a server, such as an access server, a central server or alocal server.

DETAILED DESCRIPTION OF THE INVENTION

The invention relates to improved approaches for decentralized keygeneration. The keys that can be generated include both public keys andprivate keys. The public keys are arbitrary strings that embed or encodeaccess restrictions. The access restrictions are used to enforce accesscontrol policies. The public keys are used to encrypt some or allportions of files. The private keys can be generated to decrypt theportions of the files that have been encrypted with the public keys. Bygenerating keys in a decentralized manner, not only are key distributionburdens substantially eliminated but also off-line access to encryptedfiles is facilitated. The present invention is particularly suitable inan enterprise environment.

As used herein, a user may mean a human user, a software agent, a groupof users, a member of the group, a device and/or application. Besides ahuman user who needs to access a secured document, a softwareapplication or agent sometimes needs to access secured files in order toproceed. Accordingly, unless specifically stated, the “user” as usedherein does not necessarily pertain to a human being.

Secured files are files that require one or more keys, passwords, accessprivileges, etc. to gain access to their content. According to oneaspect of the present invention, the security is provided throughencryption and access rules. The files, for example, can pertain todocuments, multimedia files, data, executable code, images and text. Ingeneral, a secured file can only be accessed by authenticated users withappropriate access rights or privileges. Each secured file is providedwith a header portion and a data portion, where the header portioncontains, or points to, security information. The security informationis used to determine whether access to associated data portions ofsecured files is permitted.

In the following description, numerous specific details are set forth inorder to provide a thorough understanding of the present invention.However, it will become obvious to those skilled in the art that thepresent invention may be practiced without these specific details. Thedescription and representation herein are the common meanings used bythose experienced or skilled in the art to most effectively convey thesubstance of their work to others skilled in the art. In otherinstances, well-known methods, procedures, components, and circuitryhave not been described in detail to avoid unnecessarily obscuringaspects of the present invention.

Reference herein to “one embodiment” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment can be included in at least one embodiment of theinvention. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment, nor are separate or alternative embodiments mutuallyexclusive of other embodiments. Further, the order of blocks in processflowcharts or diagrams representing one or more embodiments of theinvention do not inherently indicate any particular order nor imply anylimitations in the invention.

Embodiments of the present invention are discussed herein with referenceto FIGS. 1A-11. However, those skilled in the art will readilyappreciate that the detailed description given herein with respect tothese figures is for explanatory purposes as the invention extendsbeyond these limited embodiments.

FIG. 1A shows a basic system configuration in which the presentinvention may be practiced in accordance with one embodiment thereof.Documents or files may be created using an authoring tool executed on aclient computer 100, which may be a desktop computing device, a laptopcomputer, or a mobile computing device. Exemplary authoring tools mayinclude application programs such as Microsoft Office (e.g., MicrosoftWord, Microsoft PowerPoint, and Microsoft Excel), Adobe FrameMaker andAdobe Photoshop.

According to one embodiment, the client computer 100 is loaded with aclient module that is capable of communicating with a server 104 or 106over a data network (e.g., the Internet or a local area network).According to another embodiment, the client computer 100 is coupled tothe server 104 through a private link. As will be further explainedbelow, a document or file created by an authoring tool can be secured bythe client module. The client module, when executed, is configured toensure that a secured document is secured at all times in a store (e.g.,a hard disk or other data repository). The secured documents can only beaccessed by users with proper access privileges. In general, an accessprivilege or access privileges for a user may include, but not belimited to, privileges pertaining to viewing, copying, printing,editing, transferring, uploading/downloading, and location.

According to one embodiment, a created document is caused to go throughan encryption process that is preferably transparent to a user. In otherwords, the created document is encrypted or decrypted under theauthoring application so that the user is not aware of the process. Akey (referred to herein as a user key) can be used to retrieve a filekey to decrypt an encrypted document. Typically, the user key isassociated with an access privilege for the user or a group of users.For a given secured document, only a user with a proper access privilegecan access the secured document.

In one setting, a secured document may be uploaded via the network 110from the computer 100 to a computing or storage device 102 that mayserve as a central repository. Although not necessary, the network 110can provide a private link between the computer 100 and the computing orstorage device 102. Such link may be provided by an internal network inan enterprise or a secured communication protocol (e.g., VPN and HTTPS)over a public network (e.g., the Internet). Alternatively, such link maysimply be provided by a TCP/IP link. As such, secured documents on thecomputer 100 may be remotely accessed.

In another setting, the computer 100 and the computing or storage device102 are inseparable, in which case the computing or storage device 102may be a local store to retain secured documents or receive securednetwork resources (e.g., dynamic Web contents, results of a databasequery, or a live multimedia feed). Regardless of where the secureddocuments or secured resources are actually located, a user, with properaccess privilege, can access the secured documents or resources from thecomputer 100 or the computing or storage device 102 using an application(e.g., Internet Explorer, Microsoft Word or Acrobat Reader).

The server 104, also referred to as a local server, is a computingdevice coupled between a network 108 and the network 110. According toone embodiment, the server 104 executes a local version of a servermodule. The local version is a localized server module configured toservice a group of designated users or client computers, or a location.Another server 106, also referred to as a central server, is a computingdevice coupled to the network 108. The server 106 executes the servermodule and provides centralized access control management for an entireorganization or business. Accordingly, respective local modules in localservers, in coordination with the central server, form a distributedmechanism to provide distributed access control management. Suchdistributed access control management ensures the dependability,reliability and scalability of centralized access control managementundertaken by the central server for an entire enterprise or a businesslocation.

FIG. 1B shows another system configuration in which the invention may bepracticed in accordance with an embodiment thereof. Here, theconfiguration employs a central server and local servers. Theconfiguration may correspond to a large enterprise having multiplegeographic locations or offices. A central server 106 maintains adatabase managing the access privileges and the access rules in theentire enterprise. One of the features in this configuration is theunderlying capability to provide fault tolerance and efficient AC(Access Control) management for a large group of users. Instead ofhaving the central server 106 performing the AC management for each ofthe users at one single location, a number of local servers 104 (e.g.,104-A, 104-B, . . . and 104-N) are employed in a distributed manner toservice the individual locations or offices. Each of local servers 104executes a local module derived or duplicated from the server modulebeing executed at the central server 106 to manage those users who arelocal to respective local servers 104. The central server 106 cancentralize the AC management in addition to managing the users ifnecessary.

According to one embodiment, a local module can be a customized versionof the server module that runs efficiently for only a few locations or agroup of users. For example, a local server 104-A is only responsiblefor the users or computers 102-A in location A, while a local server104-B is only responsible for the users or computers 102-B in locationB. As a result, even if the central server 106 has to be taken down formaintenance or is not operative at the time a user needs to accesssecured documents, the access control will not be disrupted. Thedetailed operation of the local servers 104 in cooperation with thecentral server 106 will be further described below.

According to another embodiment, a local module is a replicated versionof the server module and exchanges any updates with the server modulewhen connected (e.g., periodically or at request). Depending onimplementation, part or all of the server module can be duplicated in alocal server to ensure that communications with users or their clientmachines are efficient and fault tolerance. As a result, even if thecentral server 106 has to be taken down for maintenance or is notoperative at the time a user needs to access secured documents, theaccess control will not be disruptive. For example, in such a situation,any of the local servers 104 can step up and take the place of thecentral server. When the central server 106 is running or communicatingwith the local servers 104, information collected at the respectivelocal servers about the users or their activities is sent back to thecentral server 106. The detailed operation of the local servers 104 incooperation with the central server 106 in this regard will also befurther provided below.

FIG. 1C shows still another system configuration in which the inventionmay be practiced in accordance with an embodiment thereof. Thisconfiguration is suitable for a small group of users. In thisconfiguration, no local servers are employed. A server computer 112 isloaded with the server module and each of the users or terminalcomputers 116 (only one is shown therein) is loaded with a clientmodule. The users or the terminal computers 16 couple to the servercomputer 112 through a local area network. The server computer 112performs the AC management for each of the users or the terminalcomputers 116.

FIG. 1D shows internal construction blocks of a computing device 118 inwhich one embodiment of the present invention may be implemented andexecuted. The computing device 118 may correspond to a client device(e.g., computer 100, computing or storage device 102 in FIG. 1A) or aserver device (e.g., server 104, 106 in FIG. 1A). As shown in FIG. 1B,the computing device 118 includes a central processing unit (CPU) 122interfaced to a data bus 120. The CPU 122 executes instructions toprocess data and perhaps manage all devices and interfaces coupled todata bus 120 for synchronized operations. The instructions beingexecuted can, for example, pertain to drivers, operating system,utilities or applications. Device interface 124 may be coupled to anexternal device, such as the computing device 102 of FIG. 1A; hence, thesecured documents therefrom can be received into memory 132 or storage136 through data bus 120. Also interfaced to data bus 120 is a displayinterface 126, a network interface 128, a printer interface 130 and afloppy disk drive interface 138. Generally, a client module, a localmodule or a server module of an executable version of one embodiment ofthe present invention can be stored to storage 136 through floppy diskdrive interface 138, network interface 128, device interface 124 orother interfaces coupled to data bus 120. Execution of such module bythe CPU 122 can cause the computing device 118 to perform as desired inthe present invention. In one embodiment, the device interface 124provides an interface for communicating with a capturing device 125(e.g., a fingerprint sensor, a smart card reader or a voice recorder) tofacilitate the authentication of a user of the computing device 118.

Main memory 132, such as random access memory (RAM), is also interfacedto data bus 120 to provide the CPU 122 with instructions and access tomemory storage 136 for data and other instructions. In particular, whenexecuting stored application program instructions, such as for documentsecuring or document accessing, the CPU 122 is caused to manipulate thedata to achieve results contemplated by the program instructions.Read-only memory (ROM) 134 is provided for storing executableinstructions, such as a basic input/output operation system (BIOS) foroperation of keyboard 140, display 126 and pointing device 142 which maybe present.

In one embodiment, the computing device 118 is capable of storingsecured items (e.g., secured files) in the main memory 132 or thestorage 136. The main memory 132 provides non-persistent (i.e.,volatile) storage for the secured items and the storage 136 providespersistent (i.e., non-volatile) storage for the secured items. Hence,the computing or storage device 102, or more particularly, the mainmemory 132 and/or the storage 136, can act as a storage device for thesecured items.

Referring now to FIG. 2A, a block diagram of securing a created document200 is shown according to one embodiment of the invention. For example,the created document 200 is a created file. After the document 200 iscreated, edited or opened with an application or authoring tool (e.g.,Microsoft Word), upon an activation of a command, such as “Save,” “SaveAs” or “Close”, or automatic saving invoked by an operating system, theapplication itself or an approved application, the created document 200is caused to undergo a securing process 201. The securing process 201starts with an encryption process 202, namely the document 200 that hasbeen created or is being written into a store is encrypted by a cipher(e.g., an encryption process) with a file key (i.e., a cipher key), inother words, the encrypted data portion 212 could not be opened withoutthe file key. For the purpose of controlling the access to the contentsin the document 200 or the resultant secured file 208, the file key orkeys may be the same or different keys for encryption and decryption andare included as part of security information contained in or pointed toby a header 206. The file key or keys, once obtained, can be used todecrypt the encrypted data portion 212 to reveal the contents therein.

To ensure that only authorized users or members of an authorized groupcan access the secured file 208, a set of access rules 204 for thedocument 200 is received or created and associated with the header 206.In general, the access rules 204 determine or regulate who and/or howthe document 200, once secured, can be accessed. In some cases, theaccess rules 204 also determine or regulate when or where the document200 can be accessed.

In addition, security clearance information 207 can be added to theheader 206 if the secured file 208 is classified. In general, thesecurity clearance information 207 is used to determine a level ofaccess privilege or security level of a user that is attempting toaccess the contents in the secured file 208. For example, a secured filemay be classified as “Top secret”, “Secret”, “Confidential”, and“Unclassified”. According to one embodiment, the security clearanceinformation 207 includes another layer of encryption of the file keywith another key referred to herein as a clearance key. An authorizeduser must have a clearance key of proper security level in addition toan authenticated user key and proper access privilege to retrieve thefile key. As used herein, a user key or a group key is a cipher keyassociated with an authenticated user and may be used to access asecured file or secure a file, or create a secured file. Additionaldetail on obtaining such a user key upon a user being authenticated isprovided in U.S. patent application Ser. No. 10/074,194, which is herebyincorporated herein by reference.

According to another embodiment, the security clearance information 207includes a set of special access rules to guard the file key. Theretrieval of the file key requires that the user pass an access rulemeasurement. Since access privilege of a user may be controlled via oneor more system parameters (e.g., rules or policies), the access rulemeasurement can determine if the user has sufficient access privilege toretrieve the file key in conjunction with the corresponding user key.

In accordance with the security clearance information 207, a user may beassigned a hierarchical security clearance level based on, perhaps, alevel of trust assigned to the user. A level of trust implies that oneuser may be more trusted than another and hence the more trusted usermay access more classified files. Depending on implementation, a levelof trust may be based on job responsibility of the user or a role of theuser in a project or an organization background checks, psychologicalprofiles, length of service, etc. In any case, a level of trust assignedto the user augments additional aspect to the access privilege of theuser such that the user must have proper security clearance to access aclassified secured file even if the user is permitted by the accessrules to access the file.

In general, a header is a file structure, preferably small in size, andincludes, or perhaps links to, security information about a resultantsecured document. Depending on implementation, the security informationcan be entirely included in a header or pointed to by a pointer that isincluded in the header. The security information further includes thefile key and/or one or more clearance keys, in some cases, an off-lineaccess permit (e.g., in the access rules) should such access berequested by an authorized user. The security information is thenencrypted by a cipher (i.e., an encryption/decryption scheme) with auser key associated with an authorized user to produce encryptedsecurity information 210. The encrypted header 206, if no otherinformation is added thereto, is attached to or integrated with theencrypted data portion 212 to generate the resultant secured file 208.In a preferred embodiment, the header is placed at the beginning of theencrypted document (data portion) to facilitate an early detection ofthe secured nature of a secured file. One of the advantages of suchplacement is to enable an access application (i.e., an authoring orviewing tool) to immediately activate a document securing module (to bedescribed where it deems appropriate) to decrypt the header ifpermitted. Nevertheless, there is no restriction as to where theencrypted header 206 is integrated with the encrypted data portion 212.

It is understood that a cipher may be implemented based on one of manyavailable encryption/decryption schemes. Encryption and decryptiongenerally require the use of some secret information, referred to as akey. For some encryption mechanisms, the same key is used for bothencryption and decryption; for other mechanisms, the keys used forencryption and decryption are different. In any case, data can beencrypted with a key according to a predetermined cipher (i.e.,encryption/decryption) scheme. Examples of such schemes may include, butnot be limited to, Data Encryption Standard algorithm (DES), Blowfishblock cipher and Twofish cipher. Therefore, the operations of thepresent invention are not limited to a choice of those commonly-usedencryption/decryption schemes. Any cipher scheme that is effective andreliable may be used. Hence, the details of a particular scheme are notfurther discussed herein so as to avoid obscuring aspects of the presentinvention.

In essence, the secured document 208 includes two parts, the encrypteddata portion 212 (i.e., encrypted version of the document itself) andthe header 210 that may point to or include encrypted securityinformation for the secured document 208. To access the contents in theencrypted data portion 212, one needs to obtain the file key to decryptthe encrypted data portion 212. To obtain the file key, one needs to beauthenticated to get a user or group key and pass an access test inwhich at least the access rules in the security information are measuredagainst the user's access privilege (i.e., access rights). If thesecured file is classified, it further requires a security levelclearance on the user. In general, the security clearance level of theuser must be high enough before the file key can be retrieved.

FIG. 2B illustrates an exemplary structure of a secured document 220including a header 222 and an encrypted portion 224. The header 222includes a security information block 226 having encrypted securityinformation that essentially controls the access to the encrypteddocument 224. In a certain implementation, the header 222 includes aflag 227 (e.g., a predetermined set of data) to indicate that thedocument 220 is secured. The security information block 226 includes oneor more user IDs 228, access rules 229, at least one file key 280 andother information 231. The user IDs 228 maintain a list of authorizedusers who may be measured against the access rules 229 before the filekey 230 can be retrieved. The access rules 229 determine at least whoand how the encrypted document 224 can be accessed. Depending on animplementation, the other information 231 may be used to include otherinformation facilitating a secure access to the encrypted document 224,the example may include version numbers or author identifier.

In general, a document is encrypted with a cipher (e.g., a symmetric orasymmetric encryption scheme). Encryption is the transformation of datainto a form that is impossible to read without appropriate knowledge(e.g., a key). Its purpose is to ensure privacy by keeping informationhidden from anyone to whom it is not intended, even those who haveaccess to other encrypted data. Decryption is the reverse of encryption.Encryption and decryption generally require the use of some secretinformation, referred to as a key. For some encryption mechanisms, thesame key is used for both encryption and decryption; for othermechanisms, the keys used for encryption and decryption are different.For the purpose of controlling the access to the document, the key orkeys, referred collectively to as a file key, may be the same ordifferent keys for encryption and decryption and are preferably includedin the security information (e.g., security information block 226)contained in or pointed to by the header (header 222) and, onceobtained, can be used to decrypt the encrypted document.

To ensure that the key is not to be retrieved or accessible by anyone,the key itself is guarded by the access privileges and rules. If a userrequesting the document has the adequate access privileges given therequirement of the access rules, the key will be retrieved so as topermit the decryption of the encrypted document.

To ensure that the security information or the header (if no flag isimplemented) is not readily revealed, the header itself can be encryptedwith a cipher. Depending on an exact implementation, the cipher for theheader may or may not be identical to the one used for the document. Thekey (referred to as a user key) to decrypt the encrypted header can, forexample, be stored in a local store of a terminal device (e.g., clientcomputer) and activated only when the user associated with it isauthenticated. As a result, only an authorized user can access thesecured document.

Optionally, the two encrypted portions (i.e., the encrypted header andthe encrypted document) can be encrypted again and only decrypted by auser key. In another option, the encrypted portions (either one or all)can be error checked by error checking portion 225, such as using acyclical redundancy check to ensure that no errors have been incurred tothe encrypted portion(s) or the secured document 220.

In general, each of the users in a security system is assigned a userkey or user keys (e.g., a user public key and a private key). In somecases, the user key is also referred to as a group key if a user is amember of group (e.g., Engineering) that has uniform access privilege.In one application, the user public key is used to encrypt some or allof the security information in the header and the user private key isused to get into the security information or header for the purpose ofretrieving the file or document key so as to decrypt the encrypted dataportion or the encrypted document. Unless specified otherwise, a userkey herein indicates either or both of the user public key and theprivate key or a security key that is needed in the system to retrievethe file key to decrypt the encrypted data portion.

In a typical enterprise environment, different users may have differentaccess privileges, some may access all secured files while others mayaccess some of the secured files with restricted actions (i.e.,printing, reading or editing, but not forwarding). Whether a user canultimately achieve the access to the encrypted data portion in a securedfile is controlled by the access rules or additional key(s) in thesecurity information of the header. Limited by a user's accessprivilege, a user key associated with the user may facilitate access toall secured files.

FIG. 3A illustrates a representative data structure of a secured file300 including a header 302 and an encrypted data portion 304 accordingto one embodiment of the invention. The secured file 300 is secured byaccess rules and use of encryption. A user must possess a user key, aprotection key, a file key and sometimes a clearance key in order toaccess the secured file 300. Depending on implementation, the header 302may or may not include a flag or signature 306. In one case, thesignature 306 is used to facilitate the detection of the security natureof a secured file among other files. The header 302 includes a file keyblock 308, a key block 310 and a rule block 312. The file key block 308includes a file key 309 that is encrypted by a cipher with a protectionkey 320 (i.e., a doc-key key sometimes) and further with a clearance key322 associated with a user that attempts to access the secured file 300.Alternatively, the file key 309 is encrypted with the clearance key 322and then the protection key 320. The protection key 320 is encrypted andstored in the key block 310. In general, the key block 310 has anencrypted version of the protection key 320 and can be only accessibleby designated user(s) or group(s). There may be more than one key blocks310 in a header, wherein three key blocks are shown in FIG. 3A. Torecover or retrieve the protection key 320, a designated user must haveproper access privilege to pass an access rule test with the embeddedaccess rules in the rule block 312.

All access rules are encrypted with a user key (e.g., a public user key)and stored in the rule block 312. A user attempting to access thesecured file uses must have a proper user key (e.g., a private user key)to decrypt the access rules in the rule block 312. The access rules arethen applied to measure the access privileges of the user. If the useris permitted to access the secured file in view of the access rules, theprotection key 320 in the key block 310 is retrieved to retrieve thefile key 309 so as to access the encrypted data portion 304. However,when it is detected that the secured file is classified, which meansthat the file key can not be retrieved with only the protection key, theuser must posses a clearance key. Only the user that has the clearancekey and the retrieved protection key 320 is able to retrieve the filekey 309 and proceed with the decryption of the encrypted data portion304.

According to one embodiment, the encrypted data portion 304 is producedby encrypting a file that is non-secured. For example, a non-secureddocument can be created by an authoring tool (e.g., Microsoft Word). Thenon-secured document is encrypted by a cipher with the file key. Theencryption information and the file key are then stored in the securityinformation, namely, the file key block 308 of the header 302.

According to another embodiment, the non-secured document (data) isencrypted using the following aspects, a strong encryption using a CBCmode, a fast random access to the encrypted data, and an integritycheck. To this end, the data is encrypted in blocks. The size of eachblock may be a predetermined number or specific to the document. Forexample, the predetermined number may be a multiple of an actualencryption block size used in an encryption scheme. One of the examplesis a block cipher (i.e., a type of symmetric-key encryption algorithmthat transforms a fixed-length block of plaintext (unencrypted text)data into a block of ciphertext (encrypted text) data of the samelength. This transformation takes place under the action of a cipher key(i.e., a file key). Decryption is performed by applying the reversetransformation to the ciphertext block using another cipher key or thesame cipher key used for encryption. The fixed length is called theblock size, such as 64 bits or 128. Each block is encrypted using a CBCmode. A unique initiation vector (IV) is generated for each block.

Other encryption of the non-secured data can be designed in view of thedescription herein. In any case, the encryption information and the filekey are then stored in the security information. One aspect of thepresent invention is that the integration of a header and the encrypteddata portion will not alter the original meaning of the data that isotherwise not secured. In other words, a designated application maystill be activated when a secured file is selected or “clicked”. Forexample, a document “xyz.doc”, when selected, will activate an authoringtool, e.g., Microsoft Word, commonly seen in a client machine. After thedocument “xyz.doc” is secured in accordance with the present invention,the resultant secured file is made to appear the same, “xyz.doc” thatstill can activate the same authorizing tool, except now the securedfile must go through a process to verify that a user is authenticated,the user has the proper access privilege and (if imposed) sufficientsecurity clearance.

Further, with the protection key, the file key can be updated withouthaving to modify the key-blocks. For example, with respect to FIG. 3A,the file key 309 in the file key block 30 can be updated without havingto modify the key-blocks 310. One of the features in the structure shownin FIG. 3A is that the underlying mechanism facilitates the updating andmanagement of the file key.

In the above-described embodiment in FIG. 3A, the access rules wereencrypted with a user's public key. Those skilled in the art canappreciate that the access rules can be encrypted in other ways. Forexample, the access rules may be also encrypted with a file encryptionkey (i.e., the file key) or the protection key. In this case, theprotection key is encrypted with a user's public key or together with aclearance key associated with the user if a subject secured file issecured. Alternatively, instead of retrieving the protection key afterthe access rules are successfully measured against access privilege ofthe user attempting to access a secured file, the protection key can beretrieved first with a user's private key. The protection key can beused to retrieve the access rules that are subsequently used to measureagainst the access privilege of the user if the protection key was usedto encrypt the access rules. If the user is permitted to access thecontents in the file, the file key is then retrieved with the protectionkey (or together with the clearance key). Alternatively, right after theprotection key is retrieved, the protection key (or together with theclearance key) is used to retrieve the file key. The file key is then toretrieve the access rules that are subsequently used to measure againstthe access privilege of the user. In any case, if the user is determinedhave sufficient access privilege in view of all access policies, ifthere are any, the retrieved file key can be used to continue thedecryption of the encrypted data portion.

It should be noted that the header in a secured document may beconfigured differently than noted above without departing from theprinciples of the present invention. For example, a secured document mayinclude a header with a plurality of encrypted headers, each can beaccessible only by one designated user or a group users. Alternatively,a header in a secured document may include more than one set of securityinformation or pointers thereto, each set being for one designated useror a group of users while a single file key can be used by all. Some orall of the access rules may be viewed or updated by users who can accessthe secured document.

In another alternative representative data structure for a secured file,the header can include at least one pointer which points to a remotedata structure stored in a storage device. The remote data structure canstore some or all of the security information, thereby shortening thesize of the header and improving manageability of security information.The storage device is typically a local storage device. In other words,the alternative data structure and the remote data structure aretypically stored on a common machine (e.g., desktop or portablecomputer). The data structure stores security information. Additionaldetails on the alternative data structure can be found in U.S.application Ser. No. 10/132,712 (Att. Dkt.: SSL1P005/SS-14), filed Apr.26, 2002, and entitled “METHOD AND SYSTEM FOR PROVIDING MANAGEABILITY TOSECURITY INFORMATION FOR SECURED ITEMS,” which is hereby incorporatedherein by reference.

According to one embodiment, the access rules are present in adescriptive language such as text or a markup language (e.g., HTML, SGMLand XML). In a preferred embodiment, the markup language is eXtensibleAccess Control Markup Language (XACML) that is essentially an XMLspecification for expressing policies for information access. Ingeneral, XACML can address fine-grained control of authorizedactivities, the effect of characteristics of the access requestor, theprotocol over which the request is made, authorization based on classesof activities, and content introspection (i.e., authorization based onboth the requestor and attribute values within the target where thevalues of the attributes may not be known to the policy writer). Inaddition, XACML can suggest a policy authorization model to guideimplementers of the authorization mechanism.

In general, the data portion of a secured item is a document or fileencrypted with a cipher (e.g., a symmetric or asymmetric encryptionscheme). Encryption is the transformation of data into a form that isimpossible to read without appropriate knowledge (e.g., a key). Itspurpose is to ensure privacy by keeping information hidden from anyoneto whom it is not intended, even those who have access to otherencrypted data. Decryption is the reverse of encryption. Encryption anddecryption generally require the use of some secret information,referred to as a key. For some encryption mechanisms, the same key isused for both encryption and decryption; for other mechanisms, the keysused for encryption and decryption are different.

For the purpose of controlling the access to the document, the key orkeys, referred collectively to as a file key, may be the same ordifferent keys for encryption and decryption and are preferably includedin the security information contained in, or pointed to by, the headerand, once obtained, can be used to decrypt the encrypted document. Toensure that the key is not to be retrieved or accessible by anyone, thekey itself is guarded by the access privileges and rules. If a userrequesting the document has the proper access privileges that can begranted by the access rules and system policies if there are any, thekey will be retrieved to proceed with the decryption of the encrypteddocument.

To ensure that the security information or the header is not readilyrevealed, at least a portion of the header itself can be encrypted witha cipher. Depending on an exact implementation, the cipher for theheader may or may not be identical to the one used for the document. Thekey (referred to as a user key) to decrypt the encrypted header can, forexample, be stored in a local store of a terminal device and activatedonly when the user associated with it is authenticated. As a result,only an authorized user can access the secured document. In oneembodiment, the key is associated with a user's login to a local serveror a central server. Appropriate access privileges associated with theuser can then be validated if the user has been authenticated orpreviously registered with the server and properly logged in.Optionally, the two portions (i.e., the header (possibly encrypted) andthe encrypted document) can be encrypted again and only decrypted by auser key. In another option, the encrypted portions (either one or all)can be error-checked by an error-checking portion, such as using acyclical redundancy check to ensure that no errors have been incurred tothe encrypted portion(s) of the secured document.

The security system according to the invention can, in general, includeor make use of one to many user computers and at least one centralserver. The security system can also include or make use of one or morelocal servers as desired. In other words, the security systems operatein a distributed fashion.

Referring now to FIG. 3B, there is shown a functional block diagram of aserver device 320 in accordance with one embodiment of the invention.The server device includes a server module 322 that resides in a memoryspace 323 and is executable by one or more processors 321. The serverdevice 320 also includes a network interface 324 to facilitate thecommunication between the server 320 and other devices on a network, anda local storage space 325. The server module 322 is an executableversion of one embodiment of the present invention and delivers, whenexecuted, features/results contemplated in the present invention.According to one embodiment, the server module 322 comprises anadministration interface 326, an account manager 328, a system parametermanager 330, a user monitor 332, a local server manager 334, a partneraccess manager 336, an access report manager 338, and a rules manager339.

Administration Interface 326:

As the name suggests, the administration interface 326 facilitates asystem administrator to register users and grant respective accessprivileges to the users and is an entry point to the server module fromwhich all sub-modules or the results thereof can be initiated, updatedand managed. In one embodiment, the system administrator sets uphierarchy access levels for various active folders, storage locations,users or group of users. The privileges may include, but not be limitedto: open, read, write, print, copy, download and others Examples of theother privileges are altering access privileges for other users,accessing secured documents from one or more locations, and setting up aset of access rules for a folder different from those previously set up(perhaps by the system administrator). The respective user IDs assignedto the users facilitate the management of all the users. Unlessspecifically stated differently, a user or a corresponding user ID isinterchangeably used herein to identify a human user, a software agent,or a group of users and/or software agents. Besides a human user whoneeds to access a secured document, a software application or agentsometimes needs to access the secured document in order to proceedforward. Accordingly, unless specifically stated, the “user” as usedherein does not necessarily pertain to a human being. In general, a userthat will access a secured document is associated with a user key toallow an encrypted header in a secured document to be unlocked(decrypted). The expiration or regeneration of a user key may beinitiated by the system administrator. According to one embodiment, theadministration interface 326 is a user graphic interface showing optionsfor various tasks that an authenticated system administrator or operatormay need to perform.

Account Manager 328:

Essentially, the account manager is a database or an interface to adatabase 327 (e.g., an Oracle database) maintaining all the registeredusers and their respective access privileges, and perhaps correspondinguser keys (e.g., private and public keys). In operation, the accountmanager 328 authenticates a user when the user logs onto the server 320and also determines if the user can access secured documents from thelocation the user's current location.

System Parameters Manager 330:

This module is configured to manage system parameters within the servermodule 322. These system parameters include, for example, user accessprivileges, system rules, and one or more keys. The system parametersmanager 330 can be used to add, delete or modify any of the systemparameters. The system parameters manager 330 can also interact withlocal modules and client modules to supply the system parameters tothese distributed modules. For example, a user key can be expired(deleted) for security reasons when a user leaves the organization orwhen its time to replace the user key. As another example, a file keymay be rotated on a periodic or on-demand basis. The system parameterscan be supplied to local modules and client modules by a “push” ofsystem parameters to the other distributed modules or by a response to a“pull” request for updated system parameters. Optionally, the systemparameters manager 330 may be further configured to act as a key managermanaging all keys used in the security system.

User Monitor 332:

This module is configured to monitor user's requests and whereabouts.Typically, a user is granted to access secured documents from one ormore designated locations or networked computers. If a user has a higheraccess privilege (e.g., to permit access from other than the locationsor networked computers), the user monitor 332 may be configured toensure that the user can have only one access from one of the registeredlocations or computers at all times. In addition, the user monitor 332may be configured and scheduled to interact with the system parametersmanager 330 to “push” an update of system parameters or respond to a“pull” request for an update of system parameters.

Local Server Manager 334:

This module is designed to be responsible for distributing anappropriate local module for a local server servicing a predeterminedlocation or a predetermined group of users. According to one embodiment,the local server manager 334 replicates some or all of the server module322 being executed on the server 320 and distributes the replicated copyto all the local servers. As a result, a user can access secureddocuments anywhere within the network premises covered by the localservers without being authenticated at a single central server, namelythe server 320. According to another embodiment, the local servermanager 334 replicates some of the server module 322 being executed onthe server 320 and distributes the replicated copy to a correspondinglocal server, in this embodiment, each of the local servers will haveits own customized replication from the server module 322.

Partners Access Manager 336:

A special module to manage non-employees accounts. The non-employees maybe consultants to a business that requires the consultants to accesscertain secured documents. The partners access manager 336 generallyworks in accordance with other modules in the server but puts additionalrestrictions on such users being directly managed by the partners accessmanager 336. In one application, the partners access manager 336generates a request to the user key manager 330 to expire a key or keypair for a consultant when an engagement with the consultant ends.

Access Report Manager 338:

A module is configured to record or track possible access activities andprimarily works with a corresponding sub-module in a client module beingexecuted in a client machine. The access report manager 338 ispreferably activated by the system administrator and the contentsgathered in the access report manager 338 and is typically onlyaccessible by the system administrator.

Rules Manager 339:

In general, the rules manager 339 is an enforcement mechanism of variousaccess rules. According to one aspect, the rules manager 339 isconfigured to specify rules based on i) data types (e.g., MicrosoftWord), ii) group users or individual, iii) applicable rights, and iv)duration of access rules. Typically, a set of rules is a policy (namely,a security policy). A policy can be enabled, disabled, edited, deployedand undone (e.g., one or two levels). Policies managed by the rulesmanager 339 operate preferably on a global level. The rules (as well asother system parameters) are typically downloaded to the client machineduring the login process (after the user is authenticated) and can beupdated dynamically. In addition, respective policies may be associatedwith active folders (i.e., those designated places to store secureddocuments). These polices are also downloaded and updated on the clientmachine. Simple policies can also be embedded in the document andprovide document specific policies.

According to one embodiment, a header is received by a local server froma client and the access rules from the header are retrieved. The keymanager 330 can be called upon to decrypt the encrypted securityinformation in the header. The rules manager 339 can then parse theaccess rules from the security information and evaluate or measure theaccess rules against the access privileges of the user to determinewhether the secured document can be accessed by the user. If theevaluation or measurement succeeds, a file key is retrieved and sentback to the client.

It should be pointed out that the server module 322 in FIG. 3B listssome exemplary modules according to one embodiment of the presentinvention and not every module in the server module 322 has to beimplemented in order to practice the present invention. Those skilled inthe art can understand that given the description herein, variouscombinations of the modules as well as modifications thereof withoutdeparting the spirits of the present invention, may achieve variousdesired functions, benefits and advantages contemplated in the presentinvention.

FIG. 3C shows a functional block diagram of a local server device 340according to one embodiment of the invention. The local server device340 executes a module, referred herein as a local module 342 which isconfigured to be a complete or partial replication of the server module322 of FIG. 3B. The local server device 340 is generally similar to thatof a server as illustrated in FIG. 3B. Namely, the local server device340 includes one or more processors 341, a memory space 343, a networkinterface 344, and a local storage space 345. Given the similarity, manyparts illustrated in FIG. 3C are not to be described again to avoidobscuring aspects of the present invention. The local module 342provides the dependability, reliability and scalability of thecentralized access control management being undertaken by the centralserver 320 of FIG. 3B. As such, not all authentication requests need tobe handled at one central point without losing control of the accesscontrol management. The users are thus not affected if the centralserver is brought down for maintenance and the connection to the centralserver is not available. If a number of local servers are used and eachhas a replication of the server module, the reliability of servicing theusers is greatly enhanced. As a result, the local users need only tocheck with the corresponding local server and none of the users would beaffected if other local servers are down for whatever reasons ordisconnected from the central server.

The configuration of a user's access to secured documents is sometimesreferred to as a provisioning process. The dynamic provisioning that hasbeen deserted above is believed to provide the necessary security meansneeded by a large enterprise having employees in several locationswithout the loss of the centralized access control management at acentral server. Further, the use of multiple local servers to supportthe central server can provide increased dependability, reliability andsociability.

Referring now to FIG. 3D, there is shown a functional block diagram of aclient machine 360 according to one embodiment of the invention. As usedherein, the client machine 360 is a computing device primarily used by auser to access secured documents. The client machine 360 can, forexample, be a desktop computer, a mobile device or a laptop computer.According to one embodiment, the client machine 360 includes a processor361, a client module 362, a memory space 363, a network interface 365and a local store 367. The client module 362 resides in the memory space363 and, when executed by the processor 361, delivers features,advantages and benefits contemplated in the present invention. Throughthe network interface 365, the client machine 360 is capable ofcommunicating over a data network with other computers, such as aserver. From the client machine 360, a user can access secured documentslocated in a repository (store) 366 that may be in the client machine360, another networked device, or other storage means. According to oneembodiment, the client module 362 includes a number of sub-modulesincluding an access report module 364, a user verifying module 370, akey manager 368, a document securing module 371 and an off-line accessmanager 374.

Access Report Module 364:

This module is a software agent configured to record access activity andassociated with an authenticated user. It reports to an access reportmodule in the central server so that a record may be established as towhat secured document has been accessed by which user during what time.In particular, the access report module 364 can be activated to captureaccess activities of the user when the client machine is not networked.The access activities will be later synchronized with the counterpart inthe server to facilitate the access control management for the offlineaccess.

Key Manager 368:

One of the purposes for the key manager 368 is to ensure that a secureddocument is still usable when the secured document is being accessed byan application that suddenly crashes. According to one embodiment, afterthe encrypted header is decrypted, the file key is then copied or a copythereof is stored (cached) into the key manager 368. The file key isthen used to decrypt the encrypted document. A clear document is nowavailable to the application. If the application crashes due to poweroutage or interfered by another application or OS, the file key in theheader could be damaged. If no copy of the file key is available, thesecured document may not be usable any more because the encrypteddocument would not be decrypted without the file key. In this case, thereserved key maintained in the key manager 368 can be used to replacethe damaged key and decrypt the encrypted document. After the user savesthe file again, the file key is put back into the header. Anotherpurpose for the key manager 368 is to cache a user key or keys of anauthenticated user.

User Verifying Module 370:

This module is responsible for determining if a user accessing a secureddocument has been authenticated otherwise it will initiate a request forauthentication with a local server or a central server. In other words,the user verifying module 370 is always consulted before a permission isgranted to the user seeking access to a secured document. According toone embodiment, a user key or keys of an authenticated user are stored(cached) in the key manager 368 once the user is authenticated by theuser verifying module 370 via the server. When a secured document isaccessed, the user key must be retrieved from the key manager 368 todecrypt the encrypted security information in the header of the secureddocument.

Document Securing Module 371:

As described above, the DSM 371 includes a cipher 372 that is used togenerate a file/user key and encrypt/decrypt a document/header. Inaddition, other securing means may be implemented in the DSM 371, forexample, a filter to block copying contents in a secured document into anon-secured document or a link from a secured document/original sourceto another document or recipient source.

Off-Line Access Manager 374:

This module becomes effective only when the networked client machine isoff the network, namely, the communication with a local server or acentral server is not currently available. For example, a user is on theroad and still needs to access some secured documents in a laptopcomputer. When five consultation is not available, the off-line accessmanager 374 is activated to ensure that the authorized user still canaccess the secured document but only for a limited time and perhaps witha limited privilege.

It should be pointed out that the client module 362 in FIG. 3D listssome exemplary sub-modules according to one embodiment of the presentinvention and not every module in the server module 362 has to beimplemented in order to practice the present invention. Those skilled inthe art can understand that given the description herein, variouscombinations of the sub-modules, may achieve certain functions, benefitsand advantages contemplated in the present invention.

According to one aspect of the invention, keys that are used to securefiles can use arbitrary strings. Such keys are preferably public keys(also known as identity based public keys) that are used to encryptfiles (or documents). Specifically, the public keys are arbitrarystrings that embed or encode access restrictions (or access rules). Theaccess restrictions are used to enforce access control policies.Counterpart private keys are used to decrypt the files that have beenpreviously encrypted with the public keys. The private keys can begenerated to decrypt the portions of the files that have previously beenencrypted with the public keys.

Because the public keys are based on arbitrary strings, the public keysand their private key counterparts are able to be generated in adecentralized manner (as well as in a centralized manner). The abilityto generate keys in a decentralized manner substantially eliminates keydistribution burdens and facilitates off-line access to encrypted files.In the embodiments discussed below, the public keys which are based onarbitrary strings are preferably used as file keys to secure files.Often, the file keys are symmetric keys. However, in other embodiments,arbitrary strings can be used with other public keys besides file keys.Such other public keys might, for example, be associated with user keys(also known as a group key when the key pertains to a group of users),clearance keys, or protection keys.

FIG. 4 is a block diagram of a file security system 400 according to oneembodiment of the invention. The file security system 400 includes anaccess server 402 and client machines 404 and 406. The access server 402can pertain to a local server or a central server as noted above withrespect to FIGS. 1A-1C. The access server 402 couples to a network 408,and the client machines 404 and 406 also couple to the network 408. Thenetwork 408, for example, can pertain to one or more of the Internet, awide area network, a local area network, etc.

The access server 402 includes an access manager 410 and a key generator412 with a rules engine. The access manager 410 provides centralizedcontrol for management of user access to secured files. The securedfiles can be associated with the access server, such as stored in a filestore 414, or associated with client machines 404 and 406 and stored infile stores such as a file store 416 or a file store 418. The accessmanager 410 communicates with the key generator 412 to decide whether aparticular user is granted access to a secure file. In this regard, thekey generator 412 within the rules engine evaluates the rules (e.g.,access rules) that are associated with the secure file to be accessed.If the rules engine 412 determines that the access requested ispermissible, then the key generator 412 generates a key that can beutilized in gaining access to the secure file. The generated key issupplied to the access manager 410. The access manager 410 can eithergain access to the secured file using the generated key or can supplythe generated key to the appropriate client machine which in turn gainsaccess to the secured file using the generated key. In one embodiment,the generated key can be referred to as a file key.

FIG. 5 is a block diagram of a distributed file security system 500according to one embodiment of the invention. The distributed filesecurity system 500 distributes security operations to local clientmachines to distribute processing load as well as to reduce key transferand distribution across networks.

The distributed file security system 500 includes an access server 502and a representative client machine 504 coupled through a network 506.The access server 502 includes at least an access manager 508 thatcontrols access to secure files managed by the distributed file securitysystem 500. The client machine 504 couples to a file store 510 wheresecured files are stored. In addition, the client machine 504 couples toa hardware (HW) card 512 (e.g., a smart card). The hardware card 512 is,more generally, a peripheral device coupled to the client machine 504.As illustrated in FIG. 5, the hardware card 512 includes an accesscontroller 514, a key generator with rules engine 516 and a key store518.

When a user of the client machine 504 desires to access a secured filethat is managed by the distributed file security system 500, the user ofthe client machine 504 is typically first authenticated by the accessmanager 508 of the access server 502. Then, a rules string associatedwith access rules is used as a key (namely, public key) to access thesecured file. The key generator with rules engine 516 within thehardware card 512 receives the rule string and evaluates whether theuser has sufficient privileges to access the secured file in view of therules embedded within the rules string. When the key generator withrules engine 516 determines that the user is permitted access to thesecured file, the access controller 514 produces a private key which isused to decrypt the secured file. The private key can also be stored tothe key store 518. In this embodiment, the private key preferablyresides within the hardware card 512 and thus is not transmitted beyondthe hardware card 512. In other words, the private key is not stored onthe client machine 504, nor does the client key traverse the network 806to be stored in the access server 502.

FIG. 6 is a flow diagram of access rules based encryption processing 600according to one embodiment of the invention. The access rules basedencryption processing 600 is, for example, performed by the accessserver 402 illustrated in FIG. 4. The access server 402 can represent acentral server or a local server of a security system. The access server402 can also represent the server device 104, 106 illustrated in FIGS.1A and 1B. Some or all of the access rules based encryption processing600 can be performed at the client machines 404, 406 of FIG. 4 or theclient machines of FIGS. 1A-1C.

The access rules based encryption processing 600 initially obtains 602access rules to be imposed. Namely, the access rules to be imposed arethose access rules that are to be applied in securing a file. Next, arules string is produced 604 in accordance with the access rules.

The rules string can follow a predetermined format to embed the accessrules. Although the rules string can vary, one example of a rules stringis “9:00 am to 5:00 pm<Dec. 31, 2002” which encodes access rules thatindicate that access to the associated secured file is only permittedbetween 9:00 am and 5:00 pm but only prior to Dec. 31, 2002. Anotherexample is “10:00 am-2:00 pm on machine 10.200.255.213” which encodesaccess rules that indicate that access to the associated secured file isonly permitted between 10:00 am and 2:00 pm from a machine having aspecific network address. The rules string can also include an accessrule that limits access to the secured file to certain groups of users.For example, a group “human resources” could be used in an access ruleto limit access to personnel files to only those users that are deemedin the human resources group. Still another example is “Engineering,9:00 am and 5:00 pm, Mon-Fri, off-line, MS-Word” which encodes accessrules that indicate that access to the associated secured file is onlypermitted by user of the Engineering group, between 9:00 am to 5:00 pm,Monday through Friday, when off-line and when using MS-Word.

Once the rules string has been produced 604, a public key is generated606 based on the rules string. Here, the securing of the file issimplified in that the public key is derived from the rules string whichin turn includes the access rules. In other words, the public key isgenerated based on the rules string. Consequently, the public key isthus not supplied by a key generator (which would require distributionpublic/private key pairs). Thereafter, at least a portion of the file isencrypted 608 using the public key. In one embodiment, the portion ofthe file being encrypted 608 is a data portion of the file. Once theportion of the file is encrypted 608, the access rules based encryptionprocessing 600 is complete and ends.

FIG. 7 is a flow diagram of access rules based decryption processing 700according to one embodiment of the invention. The access rules baseddecryption processing 700 is performed in order to decrypt a file thathas been previously encrypted (i.e., secured file).

According to the access rules based decryption processing 700, a publickey string associated with the secured file is obtained 702. Next,access rules associated with the public key are identified 704. In oneembodiment, the access rules can be embedded in the public key string.The access rules are then evaluated 706. A decision 708 then determineswhether the access rules are satisfied. Here, the access rules can becompared against access privileges associated with the requestor thatdesires access to the secured file. These access rules are not only usedto formulate a public key, but also used to determine whether therequestor has sufficient privileges and rights to satisfy the accessrules and thus gain access to the secured file.

When the decision 708 determines that the access rules are notsatisfied, then access to the secured file is denied 710. On the otherhand, when the decision 708 determines that the access rules aresatisfied, then a private key is generated 712 based on the access rulesand a master key. In one embodiment, the private key can be referred toas a file key. After the private key has been generated 712, at least aportion of the secured file is decrypted 714 using the private key. Inone embodiment, the portion of the secured file being decrypted 714 is adata portion of the secured file. Following the operation 714, as wellas following the operation 710, the access rules based decryptionprocessing 700 is complete and ends.

As used herein, a master key is used to generate a private key. Hence,access to the master key must be restricted. In one embodiment, themaster key is generated or regenerated based on gathered information. Inthe context of the present invention, the gathered information which maybe considered a seed to generate a master key or the master key mayitself be distributed among a central server, one or more local servers,and a local device (e.g., a smart card or simply a local clientmachine). In other words, generation the master key or acquisition ofthe master key is shared among different machines, none could act aloneto obtain the master key to proceed with the processes described herein.In one embodiment, a segment of the information is stored in the centralserver, another segment of the information is stored in a local serverand a third segment of the information is stored in the local device.Only under the condition that the user is authenticated by the server(the central or local server), can the distributed segments of theinformation be gathered together to generate the master key or recoverthe master key. Further, the recovered or generated master key can, forexample, also be configured to be valid for a certain period of time orfor a fixed number of uses to enhance the security thereof.

FIG. 8 is a flow diagram of access rules based encryption processing 800according to another embodiment of the invention. The access rules basedencryption 800 is, for example, performed by a distributed file securitysystem, such as the distributed file security system 500 illustrated inFIG. 5.

The access rules based encryption processing 800 initially obtains 802access rules to be imposed when securing a file. Next, a rule string isproduced 804 in accordance with the access rules. As noted above withrespect to FIG. 6, the rules string can follow a predetermined format toembed the access rules. A key block of the file to be encrypted (orsecured) can then be obtained 806. In one embodiment, a key block is apart of a header of a file format that includes one or more keys thatare used to decrypt data within a data portion of the file format.

A public key for the key block is generated 808 based on the rulestring. Here, the public key is able to be relatively easily generatedgiven that it is based on the rules string. In other words, the publickey can be generated without requiring the generation of a private/'keypair and without the need to distribute of such keys. After the publickey for the key block has been generated 808, the key block of the fileis then encrypted 810 using the public key. The encrypted key block isthen returned 812 to the requesting device. The encrypted key block isthen able to be affixed to the encrypted data portion of the securedfile. For example, the encrypted key block can form part of the securityinformation of the header portion of the secured file. In oneembodiment, the data portion was previously encrypted using the one ormore keys within the key block.

FIG. 9 is a flow diagram of access rules based decryption 900 accordingto one embodiment of the invention. The access rules based decryptionprocessing 900 is, for example, performed by a combination of an accessserver and a hardware card associated with a distributed data securitysystem.

The access rules based decryption processing 900 initially obtains 902 apublic key string associated with a secured file. Then, access rulesassociated with the public key are identified 904. An encrypted keyblock is also obtained 906. After the access rules have been identified904, the access rules within the public key are evaluated 908. Adecision 910 determines whether the access rules are satisfied. When thedecision 910 determines that the access rules are satisfied, then aprivate key is generated 912 based on the access rules and a master key.Then, the encrypted key block is decrypted 914 to acquire a file key.Thereafter, the file key is utilized to decrypt 916 at least a portionof the secured file using the file key. In one embodiment, the at leastthe portion of the secured file pertains to a data portion of thesecured file.

On the other hand, when the decision 910 determines that the accessrules are not satisfied, then access to the secured file is denied 918.Additionally, after access to the secured file has been denied 918,additional processing can be performed to restrict unauthorized usersfrom making additional requests to access secured files. For example, adecision 920 can determine whether to “lock down” the file securitysystem to prevent further access to storage resources that storeimportant security keys. When the decision 920 determines that a lockdown should be performed, then subsequent access to the secured file,and perhaps other secured files maintained or managed by the samehardware card, are prevented 922. In other words, once the secured file,or the hardware card storing the secured filed, is locked down, thesecured file is not able to be being subsequently accessed 922.Following the operations 916 and 922, as well as following the decision920 when a lock down should not be performed, the access rules baseddecryption processing 900 is complete and ends.

In one embodiment, the operations 908 through 914 are performed internalto a tamper proof device, such as a hardware card (e.g., the hardwarecard 512 of FIG. 5). As a result, the master key and a key generationalgorithm can be stored in the hardware card in a secure manner. Theprivate key being generated can also remain internal to the hardwarecard. In another embodiment, the master key can have one part (orsegment) within the tamper proof device and another part (or segment) ona server or client machine. In such an embodiment, a securecommunication cannel can be used for communications between the variousdevices.

The results of the access rules based decryption 700, 900 can beconsidered a clear file (i.e., decrypted file or decrypted dataportion). The clear file refers to the fact that the previously securedfile is no longer secured, and is thus usable. The clear file can bereturned to the requestor. Nevertheless, the processing described abovewith respect to the access rules based decryption processing 700, 900shown in FIGS. 7 and 9 is typically preceded by authorizationprocessing. Authorization processing operates to authenticate the userseeking access to a secured file.

FIG. 10 illustrates flow diagrams of an authorization process 1000according to one embodiment of the invention. The authorization process1000 begins with a decision 1002 that determines whether a request toaccess a secured file has been received. When the decision 1002determines that such a request has not yet been received, theauthorization process 1000 waits for such a request. In other words, theauthorization process 1000 can be considered to be invoked when arequest to access a secured file is received.

Once the decision 1002 determines that a request to access a securedfile has been received, a decision 1004 determines whether the userand/or the client machine have been authenticated. Typically, therequest is initiated by a user of a client machine. For security, boththe user and the client machine are authenticated. When the decision1004 determines that both the user and the client machine have not yetbeen authenticated, then authentication processing is performed 1006.The authentication processing that is performed 1006 serves to not onlyauthenticate that the user is who the user claims he or she is, but alsoto determine that the client machine that the user is utilizing is oneauthorized to be used by the user. In the event that authentication wereto be unsuccessful, the authorization process 1000 would end and theuser would be unable to access the secured file. Additional details onauthentication processing are provided below with reference to FIG. 11.

On the other hand, when the decision 1002 determines that the user andthe client machine have already been authenticated, as well as after theauthentication processing has been performed 1006, a user key associatedwith the user is retrieved 1008. The user key can be retrieved 1008 froma storage location that is local or remote with respect to the computingdevice performing the authorization process 1000. After the user key hasbeen retrieved 1008, part or all of the security information in theheader portion of the secured file can be decrypted 1010 using the userkey. As noted above, the secured file includes a header and a dataportion. The header can include, among other things, securityinformation. One component of the security information for the securedfile is a file key. The file key can be used to decrypt the data portionof the secured file. Hence, after the security information in the headeris decrypted 1010 using the user key, the authorization processing 1000is complete and ends.

FIG. 11 shows a flowchart of a user authentication process 1100 that maybe implemented in a server, such as an access server, a central serveror a local server. As described above, there are at least two situationsthat will call upon the user authentication process 1100—initial loginto a networked client machine and first access to a secured document.When either of these situations happens, a client module in the clientmachine initiates a request that is transmitted to a server running amodule providing the access control management to start the userauthentication process 1100.

At a decision 1102, the server awaits a request (e.g., authenticationrequest) from the client machine. Upon receiving the request from theclient machine, the server proceeds at a decision 1104 to determine ifthe user and the client machine from which the user attempts to access asecured document have already been authenticated. If both have alreadybeen authenticated, processing skips to operation 1112. On the otherhand, the authentication processing 1100 continues when the decision1104 determines that the user and the client machine have not alreadybeen authenticated. In one embodiment, the server may initiate a securedlink with the client machine if both the server and the client machineare coupled to an open network, such link may be over HTTPS or supportedthrough VPN. Alternatively, there may be a direct link between theclient and the server if another authentication means is employed.

Next, the server responds 1106 to the received request with anauthentication response. Depending on implementation, such response maybe a dialog box to be displayed on the screen of the client machine, acommand or other demand. In any case, the response requires thatcredential information be provided by the user. As described before, thecredential information may be a set of username and password orbiometric information of the user and must be received from the user. Adecision 1108 then causes the authentication processing 1100 to awaitfor such credential information before the authentication processing1100 may proceed. Upon receiving the credential information, a decision1110 determines whether the user is authenticated. Here, the decision1110 can determines whether the user is authenticated to access anysecured files. If the decision 1110 determine that the user is notauthenticated, the authentication processing 1110 goes back to thebeginning of the authentication processing 1100 to continue waiting fora request. In other words, the current request to access the secureddocuments or login to the system is abandoned. If the decision 1110determines that the user is authenticated, the user is then recognizedas being authentic. At the same time, the client machine can undergo asimilar authentication by, perhaps, an IP address thereof, or a networkcard identification therein, or other means that uniquely identifies theclient machine.

After authentication of both the user and the client machine, the user'saccess privilege is activated 1112. Depending on implementation, anactivation of the user's access privilege may be a downloading of a filecontaining the access privilege to the client machine, a decryption of alocal file containing the access privilege, or simply an activation ofthe user in a memory space of the server. In any case, at this point,the user's access privilege(s) is readily accessible, thus permittingthe user to access the secured documents from the authenticated clientmachine.

As described above, according to one embodiment, the secured documentincludes two encrypted portions, the header with encrypted securityinformation and the encrypted data portion (i.e., the encrypteddocument). The two parts in the secured document are encryptedrespectively with two different keys, the file key and the user key.Alternatively, the two encrypted portions may be encrypted again withanother key (or use the same user key).

The invention also facilitates sharing secured files between differentorganizations. Here, in one embodiment, a unique company identifier canbe encoded into the rules string and thus become part of the public keyof the company. Upon receiving a secured file, a user key (a privatekey) of the company can be generated locally to access the secured file.

In the case that there are a number of sets of access rules, each for aparticular user or a group of users, it can be understood that theencrypted access rules can be integrated with other sets of theencrypted access rules in a rules block as illustrated in FIG. 3A. Assuch, access from one user or group will not affect other users orgroups but the other users or groups will see perhaps an updated versionof the encrypted document.

The invention is preferably implemented by software or a combination ofhardware and software, but can also be implemented in hardware. Theinvention can also be embodied as computer readable code on a computerreadable medium. The computer readable medium is any data storage devicethat can store data which can thereafter be read by a computer system.Examples of the computer readable medium include read-only memory,random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storagedevices, and carrier waves. The computer readable medium can also bedistributed over network-coupled computer systems so that the computerreadable code is stored and executed in a distributed fashion.

The various embodiments, implementations and features of the inventionnoted above can be combined in various ways or used separately. Thoseskilled in the art will understand from the description that theinvention can be equally applied to or used in other various differentsettings with respect to various combinations, embodiments,implementations or features provided in the description herein.

The advantages of the invention are numerous. Different embodiments orimplementations may yield one or more of the following advantages. Oneadvantage of the invention is that public keys used to encrypt files arenot generated prior to protection. Consequently, the system does notneed to generate keys in advance and then store and distribute them.Another advantage of the invention is that the public keys encode rulesthat provide access restrictions. The rules (access rules) are also usedto generate the private keys, which protects the rules from beingmodified. Still another advantage of the invention is that off-lineaccess to protected (secured) documents is facilitated. Yet stillanother advantage of the invention is that protected files are able tobe easily shared between groups within a particular organization as wellas between disparate organizations.

The foregoing description of embodiments is illustrative of variousaspects/embodiments of the present invention. Various modifications tothe present invention can be made to the preferred embodiments by thoseskilled in the art without departing from the true spirit and scope ofthe invention as defined by the appended claims. Accordingly, the scopeof the present invention is defined by the appended claims rather thanthe foregoing description of embodiments.

1. A method for encrypting a file, said method comprising: obtainingaccess rules to be imposed; producing a rules string in accordance withthe access rules; generating a public key based on the rules string; andencrypting at least a portion of the file using the public key. 2-27.(canceled)